1. Which Jira issue is this PR addressing? Make sure that there is an accompanying issue to your PR.

   Fixes SNOW-2105991

2. Fill out the following pre-review checklist:

   • I am adding a new automated test(s) to verify correctness of my new code
     • If this test skips Local Testing mode, I'm requesting review from @snowflakedb/local-testing
   • I am adding new logging messages
   • I am adding a new telemetry message
   • I am adding new credentials
   • I am adding a new dependency
   • If this is a new feature/behavior, I'm adding the Local Testing parity changes.
   • I acknowledge that I have ensured my changes to be thread-safe. Follow the link for more information: Thread-safe Developer Guidelines
   • If adding any arguments to public Snowpark APIs or creating new public Snowpark APIs, I acknowledge that I have ensured my changes include AST support. Follow the link for more information: AST Support Guidelines

3. Please describe how your code solves the related issue.

SNOW-1900040 (#3144) added row count estimation that propagates across pandas dataframe operations, including storing precise row count information for frames constructed from native pandas/python objects and frames created by read_snowflake. This PR extends that earlier work by propagating the precise row count value across certain ordered dataframe operations, namely select, union_all, and sort, which all have predictable effects on the size of the resulting frame. This PR also changes internal methods that retrieve the frame's row count (used in many operations for bounds checking or other validation) to use this cached row count value rather than issuing a query.

In short, retrieving the length of a dataframe created from native pandas/python or directly by read_snowflake will no longer issue an extra query. This reduces query counts across large parts of the test suite. Some notable affected APIs include repr, crosstab, insert, loc, iloc, iterrows, and groupby operations with by specified as a native list object.

I did not take benchmarks for most of these operations; the removal of a query should strictly represent an improvement. I did benchmark changes to the repr operation, as some more work was needed to take advantage of the cached row count for that API (following the approach taken in SNOW-1705797/#2760). At some point between 4/15 and 4/22 (dashboard metrics link; during this period the daily benchmark runner experienced some downtime due to modin versioning issues so the exact date is lost), repr for very large dataframes began taking almost twice as long as previously. I did not investigate the root cause, but this work remedies some of the performance impact.

Performance for repr(df) on this PR (b204452) vs. main (4b5feb)